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1. Claims 1-24 are pending in this application. 

2. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 

obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or 
described as set forth in section 102 of this title, if the differences between the subject 
matter sought to be patented and the prior art are such that the subject matter as a 
whole would have been obvious at the time the invention was made to a person having 
ordinary skill in the art to which said subject matter pertains. Patentability shall not be 
negatived by the manner in which the invention was made. 

3. Claims 1-24 are rejected under 35 U.S.C. 103(a) as being unpatentable over Applicant 
Admitted prior Art, hereinafter "AAPA", in reference to SyncML Initiative (including standards 
and specifications for SyncML, SyncML Representation protocol, and SyncML Sync Protocol, 
SyncML Device Management Protocol) 

4. As to claim 1 , AAPA discloses the invention substantially as claimed including a method 
for at least partially synchronizing a first data store residing on a first device and a second data 
store residing on a second device (spec, p1 , lines 17-24), the data stores each being used for 
storing data as data units in folders, the folders in combination defining a data structure (folder 
is any container of data unit, spec, p5, lines 28-31), the method comprising the first device 
sending a message to the second device (spec, p6, lines 12-18); wherein information about 
data in the first data store is transmitted in said message (spec, p5, line 32 to p6, line 24) , and 
information about a change in the data structure of the first device is also transmitted in the 
message in an element or field of the message (spec, p6, lines 2-24; and p9, lines 21-24); and 
further wherein said information about data in the first data store is placed in the message in an 
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element or field different from the element or field where the information about a change in the 
data structure is placed (part of the standard, SyncML Representation Protocol). 

5. As to claim 15, the claim is rejected for the same reasons as claim 1 above. In addition, 
AAAPA discloses a device adapted for at least partially synchronizing a first data store residing 
on the device with a second data store residing on a second device ( spec, p1, lines 17-24), the 
data stores each being used for storing data as data units in folders, the folders having 
interrelationships and so defining a data structure (folder is any container of data unit, spec, p5, 
lines 28-31), the device comprising: means for sending a message to the second device (spec, 
p6, lines 12-18); wherein information about data in the first data store transmitted in said 
message (spec, p5, line 32 to p6, line 24), and information about a change in the data structure 
the first device also transmitted the message in an element or field of the message (spec, p6, 
lines 2-24; and p9, lines 21-24); and further wherein said information about data in the first data 
store placed in the message in an element or field different from the element or field where the 
information about a change the data structure is placed (part of the standard, SyncML 
Representation Protocol). 

6. As to claim 2, AAPA discloses the element or field where the information about data in 
the first data store is placed or the element or field where the information about a change in the 
data stricture is placed is a field of the message (part of the standard, SyncML Representation 
Protocol). 

7. As to claim 3, AAPA discloses the information about data in the first data store is 
included in a data element of the message (spec, p7, lines 18-25; and p8, line 30 to p9, line 7). 
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8. As to claim 4, AAPA discloses the data element is a data element of a protocol 
command element (spec, p7, lines 18-25; and p9, lines 12-17). 

9. As to claims 5 and 6, AAPA discloses the information about a change in the data 
structure is included in a non-data element of the message, and wherein the non-data element 
is a non-data element of a protocol command element (spec, p9, lines 12-17). 

10. As to clam 7, AAPA discloses the information about a change in the data structure 
includes folder information (folder is defined to be any container of data unit, spec, p5, lines 28- 
31; and p9, lines 21-24). 

11. As to claim 8, AAPA discloses a data identification element is contained in a protocol 
command element in the message, and the protocol command element in combination with the 
data identification element indicates the information about change in the data structure of the 
first data store (spec, p7, lines 8-14; and p9, lines 8-11). 

12. As to claim 9, AAPA discloses a data identification element is included in the message 
and the information about change in the data structure of the first data store is provided in the 
data identification element (spec, p6, lines 2-24; p7, lines 8-14; and p9, lines 21-24). 

13. As to claim 10, AAPA discloses the first device functions as a client in a client-server 
protocol and the second device as a server in the client-server protocol (spec, p1, line 17 to p2, 
line 9). 
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14. As to claim 1 1 , AAPA discloses the first device functions as a server client-server 
protocol and the second device as a client in the client-server protocol, and the step of the first 
device sending the message is responsive to a client message from the second device and 
includes resolving any conflicts posed by the client message in respect to the first data store 
(spec, p1, line 17 to p2, line 9). 

15. As to claims 12 and 20, AAPA discloses the data in the data stores are used for device 
management by applications hosted on the devices (spec, p2, lines 30-33; and SyncML device 
management protocol). 

16. As to claim 13 and 21 , AAPA discloses the data in the data stores are used as user 
data by applications hosted on the devices (spec, p1, line 31 to p2, line 9). 

17. As to claim 14, a computer program product comprising a computer readable storage 
structure embodying computer program code thereon for execution by a computer processor, 
with said computer program code characterized in that includes instructions for performing the 
steps of the method of claim 1 is inherent in AAPA's disclosure and the corresponding sync 
SyncML protocol. 



18. As to claim 16, AAPA discloses the device is either a wireless communication terminal 
or a wire line communication terminal (spec, p1, lines 17-24). 
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19. As to claim 17, AAPA discloses the device functions as a client in a client-server model 
(spec, p1, lines 17-30). 

20. As to claim 18, AAPA discloses the device functions as a server in a client-server 
model, and further comprises means for receiving a request to synchronize from the second 
device, and for then sending the message in response to the request to synchronize (part of 
sync SyncML protocol). 

21. As claim 19, AAPA discloses means for receiving the message, and wherein the device 
functions as a server in a client-server model and include means for resolving conflicts posed by 
the message (spec, p1, line 17,to p2, line 9). 

22. As to claim 22, AAPA discloses a system, comprising a first device according to claim15 
And also comprising the second device hosting the second data store (spec, p1 , line 17 to p2, 
line 9). 

23. As to claim 23, AAPA discloses the first device functions as a server in a client-server 
model and the second device functions as a client in the client-server model (spec, p1, line 17 
to p2, line 9). 

24. As to claim 24, AAPA discloses the means for sending to the second device a message 
is responsive to request sent by the second device to synchronize to the second device (Part of 
Sync SyncML protocol). 
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25. AAPA may not explicitly disclose and in details the field components of the message 
between the first and the second devices, however, it would have been obvious to one skilled in 
the art at the time of the invention that applicant's disclosure does not vary from the SyncML 
Initiative (including standards and specifications for SyncML, SyncML Representation protocol, 
and SyncML Sync Protocol, SyncML Device Management Protocol). Specifically applicant 
discloses in p9, lines 21-24 that communicating changes in a directory structure is not 
problematic if the same application takes care of handling the data and handling the 
communication according to a synchronization protocol. At least it is obvious that applicant did 
not clearly point out the patentable novelty, which he or she thinks the claims present in view of 
the state of the art disclosed by the references cited, or the objections made. 

26. Applicant's arguments filed 9/16/2005 have been fully considered but they are not 
persuasive. Therefore rejection of claims 1-24 is maintained. 

27. In the remarks, applicants argued in substance that (1), claim 1 implicitly defines a 
change in a data structure as a change in folders used to contain data. (2), the prior art for 
SyncML allows only synchronization with respect to changes in data units. (3) noting that some 
claimed limitation "communicating changes in a data structure" is not problematic in view of the 
prior art is not a statement that the limitation is taught or suggested by the prior art. (4), the 
prior art does not make it problematic to determine a way to communicate such a change when 
the application communicating the change is the same as the application that creates or 
maintains the data contained in the folders. (5) it is not clear from the prior art how this might be 
done in case of more than one application placing data in the folders/ containers to which 
changes have been made. (6) the application explains that the prior art does not provide for 
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communicating changes in the data structure/folders used to contain data, which is recited in 
claim 1 . (7) SyncML Representation protocol Standard does not teach that information about 
data and information about a change in a data structure are placed in different elements or 
fields. 

28. Examiner respectfully traverses applicants' remarks. 

29. As to point (1), claiml recites in the preamble "data stores each being used for storing 
data as data units in folders, the folders in combination defining a data structure", and in one of 
the limitations " information about data ...and information about a change in the data structure .. 
is also transmitted". First, the first part of the recitation " the folders in combination defining a 
data structure" has not been given patentable weight because the recitation occurs in the 
preamble. A preamble is generally not accorded any patentable weight where it merely recites 
the purpose of a process or the intended use of a structure, and where the body of the claim 
does not depend on the preamble for completeness but, instead, the process steps or structural 
limitations are able to stand alone. See In re Hirao, 535 F.2d 67, 190 USPQ 15 (CCPA 1976) 
and Kropa v. Robie, 187 F.2d 150, 152, 88 USPQ 478, 481 (CCPA 1951). Second, the second 
part or the recitation " information about data ...and information about a change in the data 
structure .. is also transmitted", the data structure may be interpreted in the light of the 
specification as an arrangement of container of data units. Accordingly, a change in a data unit 
in the data structure may be viewed as a change in the data structure, in other words, the 
change in the data structure is a result of a change in data in the data structure. 
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30. As to point (2), the prior art as indicated in the specification (page 5, line 32 to page 6, 
line 6) allows for " a user of an application can make changes to both the data units that belong 
to the application (such as adding a new data unit or replacing a data unit with an updated 
version because the user has used the application to change the contents of the data unit, and 
so on) as well as to how the data items are stored (such as adding a new folder and moving 
some data units from an already existing folder to the new folder), i.e. to both the data units as 
well as to the folders (i.e. the overall directory structure)". The prior art also as indicated in the 
specification (page 9, lines 21-24) allows for "communicating changes in a directory structure if 
the same application takes care of handling the data and handling the communication according 
to a synchronization protocol". 

31 . As to points (3) and (4), the specification (page 9, lines 21-24) indicates that some 
claimed limitation "communicating changes in a data structure" is not problematic in view of the 
prior art. While this is not a statement that the limitation is taught or suggested by the prior art, it 
is clear indication that it would have been obvious to one skilled in the art at the time of the 
invention to use or modify such prior art in an obvious way in order to communicate changes in 
a data structure, specifically, when the application communicating the change is the same as 
the application that creates or maintains the data contained in the folders. 

32. As to point (5), applicant argues that it is not clear from the prior art how this might be 
done in case of more than one application placing data in the folders/ containers to which 
changes have been made. In response to applicant's argument that the prior art used fail to 
show certain features of applicant's invention, it is noted that the features upon which applicant 
relies (i.e., in case of more than one application placing data in the folders/ containers to which 
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changes have been made.) are not recited in the rejected claim(s). Although the claims are 
interpreted in light of the specification, limitations from the specification are not read into the 
claims. See In re Van Geuns, 988 F.2d 1 181, 26 USPQ2d 1057 (Fed. Cir. 1993). 

33. As to point (6), applicant argues that the application explains that the prior art does not 
provide for communicating changes in the data structure/folders used to contain data, which is 
recited in claim 1 . As mentioned before, the prior art as indicated in the specification (page 5, 
line 32 to page 6, line 6) allows for "a user of an application can make changes to both the data 
units that belong to the application (such as adding a new data unit or replacing a data unit with 
an updated version because the user has used the application to change the contents of the 
data unit, and so on) as well as to how the data items are stored (such as adding a new folder 
and moving some data units from an already existing folder to the new folder), i.e. to both the 
data units as well as to the folders (i.e. the overall directory structure)". In other words, the prior 
art does provide for communicating changes in the data structure/folders used to contain data, 
which is recited in claim 1. 

34. As to point (7), applicant argues that SyncML Representation Protocol Standard does 
not teach that information about data and information about a change in a data structure are 
placed in different elements or fields. The specification (page 6, line 12 to page 9, line 20) gives 
a brief about SyncML Representation Protocol Standard, and which asserts that different 
information are placed in different elements or fields. It is noted that ""SyncML message is a 
nested structure consisting of one or more elements types, and one or more SyncML messages 
can be associated with what is called a SyncML package. The SyncML Message is an individual 
XML document consisting of one or more elements each of one or more element types. The 
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document consists of a header, specified by the SyncHdr element type, and a body, specified 
by the SyncBody element type. The SyncML header specifies routing and versioning 
information about the SyncML Message. The SyncML body is a container for one or more 
SyncML Commands. The SyncML Commands are specified by individual element types. The 
SyncML Commands act as containers for other element types that describe the specifics of the 
SyncML command, including any data or meta-information. SyncML defines request commands 
and response commands. Request commands include, for example: add (a command that 
allows the originator to ask that one or more data units be added to data accessible to the 
recipient) alert (allowing the originator to notify the recipient of a condition; copy (allowing the 
originator to ask that one or more data units accessible to the recipient be copied); delete 
(allowing the originator to ask that one or more data units accessible to the recipient be deleted 
or archived); get (allowing the originator to ask for one or more data units from the recipient); 
and search (allowing the originator to ask that the supplied query be executed against one or 
more data units accessible to the recipient). The only response commands are currently: status 
(indicating the completion status of an operation or that an error occurred while processing a 
previous request); and results (used to return the data results of either a Get or Search SyncML 
Command). SyncML uses identifiers to identify data units or folders. The identifiers are included 
in what are called the Source and Target element types, and can be a combination of Uniform 
Resource Identifiers (URIs), Uniform Resource Names (URNs), and textual names. As already 
mentioned, the SyncML representation protocol (i.e. a SyncML message) is a document mark- 
up consisting of XML element types. The element types are defined in terms of their purpose or 
usage, parent elements, any restrictions on content or use and content model. The element 
types include so-called common use elements, message container elements, data description 
elements, protocol management elements, and protocol command elements. Common use 
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element types are element types used by other SyncML element types, and include, for 
example, archive, for indicating that the data specified in a delete command should be archived 
by the recipient of the delete command, rather than simply deleted. Thus the delete command 
can use the archive common use element and so is referred to as the parent element of the 
archive common use element type, this context. Another common use element type is the Cmd 
element type, which is used to specify the SyncML command referenced by a Status element 
type (and so the Status element type is the parent element in this context). Another is the 
CmdID element type, which is used to specify a SyncML message-unique command identifier, 
and can have various parent elements, including: Add, Alert, Atomic, Copy, Delete, Exec, Get, 
Map, Put, Replace, Results, Search, Sequence, Status, and Sync. Of particular note in respect 
to the invention are the common element types LocName, LocURI, Source, and Target. 
LocName used to specify the display name for the target or source address, and so can have as 
parent elements Target or Source. LOCURI specifies the target or source specific address, and 
can also have as parent elements Target or Source. The common element type Source is used 
to specify source routing or mapping information; its parent elements include: Item, Map, 
Mapltem, Search, Sync, and SyncHdr. Target is used specify target routing or mapping 
information, and its Parent Elements include: Item, Map, Mapltem, Search, Sync, and SyncHd. 
Message container element types provide basic container support for SyncML messages. Three 
such element types are: SyncML, for specifying the container for a SyncML message, and 
having no parents since it is what is called a root or document element; SyncHdr, for specifying 
the container for the revisioning information or the routing information both) in the SyncML 
message, and having as a parent element SyncML element; and SyncBody, for specifying the 
container for the body or contents of a SyncML message, and also having as a parent element 
a SyncML element. Data description elements are used as container elements for data 



Application/Control Number: 10/781,325 Page 13 

Art Unit: 2152 

exchanged in a SyncML Message; data description elements include the following element 
types: Data, for specifying discrete SyncML data, and used by (parent elements) Alert, Cred, 
Item, Status, and Search element types; Item, for specifying a container for item data, and used 
by (parent elements) Add, Alert, Copy, Delete, Exec, Get, Put, Replace, Results, and Status; 
and Meta, for specifying meta-information about the parent element type, and used by (parent 
elements) Add, Atomic, Chal, Copy, Cred, Delete, Item, Map, Put, Replace, Results, Search, 
Sequence, and Sync. The protocol management elements include, at present, only the element 
type Status, for specifying the request status code for an indicated SyncML command, and used 
by (parent element) SyncBody. Finally, there are the Protocol Command Elements. These 
include the command elements already mentioned, for example: Add, for specifying that data be 
added to a data collection, used by (parent elements) Atomic, Sequence, Sync, SyncBody; 
Delete; Replace; and so on. The above element types are set out in the standard, SyncML 
Representation Protocol, available on the Internet." 

35. From the above discussion it is again obvious that applicant did not clearly point out the 
patentable novelty, which he or she thinks the claims present in view of the state of the art 
disclosed by the references cited, or the objections made. 

36. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as 
set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
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will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the mailing date 
of this final action. 

37. Any inquiry concerning this communication or earlier communications from the examiner 
should be directed to Nabil M. El-Hady whose telephone number is (571) 272-3963. The 
examiner can normally be reached on 9:00 - 4:00. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Bunjob Jaroenchonwanit can be reached on (571) 272-3913. The fax phone 
number for the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private 
PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 
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